A conventional personal computer comprises a processor whose actions are controlled and coordinated by means of programs stored in main memory. For example, such programs may consist of operating system programs and application programs. The main memory is typically "volatile" and requires external electrical power to maintain its storage capability so that the programs in the main memory are erased whenever the electrical power is turned off or the computer is "powered down".
The computer is generally provided with additional non-volatile mass storage, typically in the form of magnetic media such as a "hard" or "floppy" disks on which relatively permanent copies of the programs can be stored. When the computer is initially turned-on or "powered up", or when an application program is loaded, some process or method must be used to both load the programs from the non-volatile mass storage into the volatile main memory and configure the programs to work with the hardware which comprises the computer.
The phrase commonly used to denote the process of loading and initializing both the operating system and the application programs is "bootstrapping" the computer or simply "booting" the computer or the application program. A boot process is a sequence of steps which are performed during the booting procedure. During the boot process, various set up parameters are usually determined by reading the contents of one or more "configuration" or "initialization" files containing a list of selected programs, definitions and parameters which are used to initialize the operating system or application program.
On earlier versions of operating systems, the configuration files were given specific, predefined names and the programs searched for these names when booted. For example, on personal computers that use the MS-DOS.RTM. operating system developed and sold by Microsoft Corporation, Redmond, Washington, the operating system definitions and the system commands are kept in two login files that work in tandem. System definitions are normally placed in a disk file which is named CONFIG.SYS and system commands are placed in disk batch file named AUTOEXEC.BAT. During the booting process, the computer will first load the device drivers and the system definitions specified in the CONFIG.SYS file and run the programs in the AUTOEXEC.BAT file. Once execution of the system commands in the AUTOEXEC.BAT file have been completed the system is ready for operation.
Operating systems also store data in files and memory locations, which data is provided to other programs, such as application programs. In general, a location in operating system stores data, and from which it provides this data to application programs,device drivers, and other programs is called herein a "repository." Repositories can include disk files, such as the CONFIG.SYS file, and memory wherein data on a floating-point processor is stored.
Programs and operating systems use the data that is stored in the repositories. For example, The MS-DOS operating system also stores, in memory, environment variables that it finds in the AUTOEXEC.BAT file. Application programs can then retrieve the contents of the environment variables and alter their own behavior based on these contents. For example, a word processing program can use the contents of the TEMP variable to locate scratchpad space on disk for temporary files.
Various application programs and system components can also read their own configuration and initialization files when they start up. For example, the WINDOWS.TM. program developed and sold by the Microsoft Corporation, Redmond, Washington is a well-known graphic interface program which has its own initialization files. When this program starts, it reads five initialization files, some of which contain parameters that specify the appearance of a user interface, a list of application programs to start automatically, and the size and location of a swap file.
Configuration and initialization files pose problems because they are difficult to maintain. For example, some operating systems such as the MS-DOS operating system referred to above use user-defined configuration files in that changes to the file are generally made by the user directly on the file in order to change the basic system configuration. User-defined configuration files require that the user know what hardware is resident on the system and also know how to edit the login files in order to properly inform the system of the presence of the hardware.
Developers of prior art installation and configuration procedures have attempted to overcome these problems by providing automatic procedures that updated the configuration and initialization files. These procedures reduced the risk of introducing errors because no human interactions were involved. For example, some operating systems automatically detect, and store data about, the presence and amount of various hardware resources, such as memory, disks, and floating-point processors, that are available on a computer. These latter operating systems relieve the user of the responsibility of actually manually editing the configuration file. Many other automatic application installation procedures also create application-specific initialization and configuration files.
However, there are still other problems. Some of these latter prior art systems, such as the OS/2.RTM. operating system developed and sold by the International business Machines Corporation, Boca Raton, Fla., use configuration and initialization files, e.g. OS2.INI, which contain binary data and cannot be updated with a traditional text editor.
Even ASCII text configuration and initialization files are difficult to maintain with a traditional text editor because text editors do not check syntax. A user or system administrator can thus introduce syntax errors or "pathological" interactions amongst entries in these files. Further, text editors do not check for missing critical sections. Hence, it is possible for a user or system administrator to create a configuration or initialization file from which the system or an application will not start.
These ad hoc solutions create other problems because of the wide variety of configuration and initialization files they create on many computers. Sometimes related data is stored in two or more files and in several directories. For example, the MS-DOS operating system typically requires entries in both CONFIG.SYS file and in AUTOEXEC.BAT file in order to use CD-ROM hardware devices.
In addition, many of the configuration and initialization files, particularly those that relate to applications programs, are poorly documented. This poses problems for operating system and application developers. They must learn the location, syntax and semantics of each of these files because no common format exists for these files.
Developers of some prior art operating system software, such as WINDOWS NT.RTM., have attempted to impose a uniform structure on the data stored in the various repositories by providing "name space" services. A name space is a collection of all the data that an operating system manages. A name space service, or "registry," stores and organizes the data into a hierarchy, much like the objects in an object oriented programming system. Each piece of data has a name and a class and can optionally have one or more values associated with it. A registry is generally accessed by a predefined set of functions or function calls called an application program interface (API) and stores all the data formerly stored in the various repositories, e.g. memory locations and files, such as CONFIG.SYS. Programs, via calls to a registry API, can request, add, modify and delete data in a name space. With a single name space service API, one documentation standard can be used by both users and application programmers.
Automatic application installation procedures call a name space service API to register the installation of application software, check for the existence of prerequisite hardware and/or software components, and, when appropriate, locate and remove superseded versions of an application.
However, the use of a single name space service poses problems for developers and users of "older" application programs and automatic installation procedures. "Older" applications and procedures are ones that assume the existence of, and directly access, configuration and initialization files with predefined names such as CONFIG.SYS. Since these names are generally coded into the program, these older application programs and procedures must be rewritten to make calls to a new API in order to run with prior art systems that provide a name space service. This problem is significant because many older applications exist and users and system administrators are reluctant to upgrade to operating systems that provide a single name space service if they cannot use their existing application programs. Forcing application developers to rewrite existing applications to use a name space server API and forcing users and system administrators to buy updated application programs is expensive, wasteful and impedes the movement to more modern and robust operating systems.